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Good afternoon, everyone, and thanks for coming today. The topic of this presentation is "A Crash Course in Tech Management." This is a subject about which I feel very passionate. 
There are a lot of bad managers in the world & I'd like there to be fewer. So I may speak very quickly. Flag me down if needed. 


Introductions 



VM (Vicky) Brasseur 


£? @vmbrasseur 
^ vmbrasseur 

openwest@vmbrasseur.com 


Thank you, H PE, for , 

loving open source! V H©Wl6lt P9CK3 TO 

Enterprise 


I'm your presenter VM Brasseur, but you can call me Vicky. You can find me on Twitter @vmbrasseur. I've had nearly 20 years in this industry. Currently I'm a 
Senior Engineering Manager at Hewlett Packard Enterprise, serving a team who works on upstream open source development. 



Prologue 


First, a quick prologue 



Slides! 


http://archive.org/details/ 
openwest 201 6 -management 


The slides are already available, for those who would like to follow along at home. I'll show this URL again at the end of the presentation. 




Every single team is different. Every organization has different needs. What I'm about to cover are the points which are more or less generally applicable 
to all teams but, naturally, your mileage may vary. 



So when you ask me specific questions, please expect me to answer with "it depends." On that note, there will be time for questions at the end of the 
session so please try to hold them until then. 
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Also, despite my managerial and business-ness, this talk is going to be light on the business and management jargon. It's less about theory than about 
what to expect in practice. That said, let's start with just a little bit of theory. 


Management Defined 
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Knowing everybody else's job doesn't 
compensate for not knowing your own. 


[ pause for people to read slide ] So what *is* management? 
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While we all THINK we know it when we see it, we're usually wrong. That's because many of us learn about management from examples and those 
examples are BAD. So let's define it... It turns out to be pretty hard to define. 


"Management is a multi-purpose organ 
that manages business 
and manages managers 
and manages workers 
and work." 

Peter Drucker, The Principles of Management 


Peter Drucker is frequently called the Father of Modern Management, so it makes sense to start with him. How does he define management? Drucker says that "Management is a multi-purpose organ that 
manages business and manages managers and manages workers and work." Well. That's sufficiently vague and recursive, isn't it? I gotta say, this isn't Drucker's best work. Let's try again. 



“Management is an individual or a group of individuals 
that accept responsibilities to run an organisation. 

They Plan, Organise, Direct, and Control all the essential 
activities of the organisation. 

Management does not do the work themselves. 

They motivate others to do the work and co-ordinate 
(i.e. bring together) all the work for achieving the 
objectives of the organisation.” 

Theo Haimann, Managing the Modern Organization 


Theo Haimann, author of 'Managing the Modern Organization,' has a definition which is considerably more specific, [read the quote] This definition works but I'm not particularly 
comfortable with it. For that, we'll turn to Mary Parker Follett. 



“Management is the art 
of getting things done 
through people.” 

Mary Parker Follett 


"Management is the art of getting things done through people." In my opinion, this is nearly the best definition of management. It's succinct while still 
hitting three important elements of management: skill, productivity, people. But it could use a little tweaking. 



craft! 

“Management is the 0<t 
of getting things done 
through people.” 

Mary Parker Follett 


Laura Thompson of Mozilla & I had a good conversation about this talk once. She suggested this correction and I agree, it's much better. Now that we 
have a working definition, let's get a little deeper into it. 


craft! 

“Management is the 0<t 

of getting things done 
through people.” 

Mary Parker Follett 


There are three main elements to this equation: Craft, Getting Things Done, and People. I'll go into each of them in some detail, starting with... 


Craft 



The Principles of 
Scientific Alanagement 
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Despite the efforts of Frederick Winslow Taylor to quantify it back in the late 1800's, management is not now and never will be a science. Management is a craft. Like most crafts, it can 
be learned but it goes more smoothly if you have an aptitude. Some of the skills you'll need to have or develop: 


A tendency toward organization. 



Not Good 
With 
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People 


Be generally good with people. ..or at least enjoy interacting with them. Empathy is the primary requirement for the job. 


Be comfortable with playing the game of office politics. 



Image courtesy of Flickr User DieselDemon; CC BY 


If you're offered the position of tech manager and you don't want to learn these skills of the craft then please politely decline the offer and walk away. 


Sometimes walking away has 
nothing to do with weakness, 

and everything to do with 

strength. We walk away not 

because we want others to realize 
our worth and value, but because 

we finally realize our own. 
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No one will fault you if you do. Not every person will enjoy or be comfortable being a manager. It's OK for you not to accept a position with which you don't feel entirely comfortable. By 
walking away you're doing a great service to yourself and to your team by not taking on a role which you will not enjoy. 



GTD 



craft! 

“Management is the 0<t 

of getting things done 

through people.” 

Mary Parker Follett 


The next important element of management is getting things done. If you're not getting things done then you're not a manager, you're just 
administrator. 



A part of the job involves project management and keeping all the ducks in a row, but I'm not going to go into project management in this talk. Project management is a part of the job 
but only a part. Project Management and Technical Management are two entirely separate but related roles. Today we're only discussing the latter of the two. 



Many people get into tech because of the interesting problems that need solving. You'll still be a problem solver as a manager, but the problems will be 
considerably different. For instance: 
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Managers have a lot of goals beyond just completing a feature, refactoring a module, adding to the test coverage, or performing usability studies. 



You'll have to attend to matters affecting enterprise profitability. 


If Satisfied... 
Tell Others 
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You'll be held directly responsible for customer satisfaction. 
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You are responsible for the efficiency of your team, your processes and your product. 
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You'll be responsible for product quality. 







THE BEATINGS WILL CONTINUE 
UNTIL MORALE IMPROVES 
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You'll be responsible for hiring, firing, performance reviews and team morale. 




You'll be called upon to make informed decisions on a daily basis. 
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The key here is informed. A great deal of your time is going to be spent gathering and parsing information to prepare you to solve problems and make the necessary decisions which are 
going to arise during your average day. 



In order to make these informed decisions, you'll need to know your product, both functionally and architecturally. If you've come from the development 
team then it's possible you already have this one covered. If not then you'll have to learn. 




You'll need to know your domain and your users, i.e., know your market. Who are they, what do they want, what are they trying to accomplish? The quickest way to get up to speed on 
this is to grab a product manager or a member of the marketing team, take her to lunch and pick her brain. 





You'll need to know your budget. Keep in mind: 'budget' means more than just money. Any limited resource must be budgeted, the most dear of which 
will always be time. 


"All men 7 can see these' 


, tactics whereby I 
xonquer, but what 
none can see is the 
strategy out of which 
flT/ictory*is evolved."^m 

' _ ~SunTzu 
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You must concern yourself with the strategy of the business, of your department, and of your team and make informed decisions to accomplish and 
balance those strategies. 



The business of tech is a series of talks all on its own, really. You'll need to know your company. What are its business goals and how does your team fit 
into them? Who are its competitors? 



mba 

master of business administration 
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Which is not to say that you need an MBA in order to be a tech manager. MBAs and management degrees can be useful and have their place, but they are 
not necessary for this job. 
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To be honest, studying poetry, philosophy, and the human condition can do almost as much to teach you about management as an MBA 


“You are certified 
by the community 
you serve.” 

Sanjit “Bunker” Roy, TED talk, October 201 1 


If you're inquisitive and diligent you can learn everything you need without dropping $1 00K on a degree. You do not need that degree to validate your skills as a manager. "You are certified by the 
community you serve" is one of my favorite quotes. It applies so well to so many things. What you do, what you say, what you deliver will speak more loudly about you than any letters after your name. 



People 



craft! 

“Management is the 0<t 
of getting things done 
through people.” 

Mary Parker Follett 


So, moving on to the most important element of management: the people. 



“Why is it that when I ask for a pair of hands 
a brain comes attached?” 


[read quote] Henry Ford was a great and influential man. He revolutionized manufacturing and changed the world. He was also an anti-Semite and, if this quote is any indicator, he must've been a first class 
jerk to work for. Your team are not just hands. Your team is the most vital asset of your company. THEY are much more important than YOU are. 



This is part of the reason I object so strongly to the term "cat herder" for what I do. It dehumanizes my team and devalues their contributions. In my opinion, if you're a tech manager 
and have to do any sort of herding— cat or otherwise— then you are doing it WRONG. 



COMMUNICATION 


You're doing it wrong 
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Managing is professionalized relationship building and maintenance. As with any relationship, the golden key to success is communication. 









Your team members will perform best when you communicate with them fully. When they not only know what it is they need to do but also why it needs to be done. What are the 
reasons leading up to the task? What does the company hope to get out of it? How will they be contributing to the greater good of the organization? What difference are they going to 
make? 


You will find that everything will go more smoothly if you're as open as possible. 










There are some very good reasons to hide or not share some information with your team. Personnel matters are entirely verboten, for instance. If your company is going IPO, get VC funding, or is in the 
middle of some sort of merger or acquisition then there are SEC laws which prevent you from sharing information. But for most matters I find that it's best to be as open as possible with my team. 
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Providing your team with as much information as possible them context, empowers them and enables them to make educated decisions in the course of 
their duties. 




The openness needs to apply to your door as well (figuratively speaking if you, as I, do not have an office let alone a door). It's important to speak regularly with your team so you can keep them informed, 
provide feedback and make sure all projects are chugging along nicely, but people must also understand that they don't have to wait for a meeting to talk to you (and it's often better if they don't). 



Doors allow traffic to pass through them in more than one direction. Don't wait for a regular meeting to provide feedback on remarkable events... 



be they good 




...or not so good. This is not the sort of information which can wait for a regular meeting. "Ya remember that thing you did two weeks ago...?" is never a good way to start feedback, 
good or bad. You should always speak with people as soon as possible after a remarkable event. 



Aside from timely, feedback also has to be effective 






Think of it like a feature request or bug report. When one of those crosses your desk, what do you want to see? 



\ 
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Details! 










This thing broke... 
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...when I did this... 


.on this platform. 



When providing feedback, include as much data as possible. Tell people what they did, when they did it, and why it was remarkable. 




Remarkable events are those which either exceed or fall short of expectations. When providing feedback, be specific in what ways what they did did not 
meet expectations (either positively or negatively). 


If communication is the key to managing then expectations are the key to communication. It is paramount that you set up expectations at every step in the 
process. 


Behavior-driven development 




In soft*?* engineering, behavKxdnven development BOO) is a software development process that 
emerged from test dnven development (TOO Behavw-dnven development contones the general techniques and 
pnnopkK of TOO with do** from domain dnven doagr and otyoct onerrtod analyse and design to provide software 
development and management tsams with shared too** and a shared process to cottaborate on software development ,4 

Although BOO « pnnopaiiy an daa about how software development shoUd Da managed by bon business interests and 
technical nsight. the practice of BOO does assume the use of specetoed software toots to support the development 
process Although these toon are often developed speoftcefty tor use to BOO projects, they can be seen as specakred 
forms of the tootng that supports test dnven develop m ent The tools serve to add automation to the udqmtous language 
that t* a central theme of BOO 

BOO is largely facilitated through the use of a ample Domain-specific language (DSL) us*ng naffira language constructs (eg, 
Engfreh-tae sentences) that can express the behavior and the expected outcomes Test scnpt* have tong been a popular 
application of DSL* with varyng degree* of eophetcebon BOO m oon*id*red a* *n effective tochmcaJ practice oepo o ePy 
when me ‘problem space* of the business problem to solve « complex 


Think of it like Behavior Driven Development for your team. We can express this in pseudo BDD terms... 


Given you are performing $role 

When Sevent 

Then you will Saction. 


Make all expectations explicit and specific. 




As I mentioned earlier, management is professionalized relationship building and maintenance. Just like any other relationship, you cannot hold people to unexpressed expectations. 
That's how relationships break up. 



Expectations will 

be the end of you 

EXCEED 

them 
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So let's say you HAVE expressed your expectations clearly. If so, then you MUST either hold people to them or tell people that an expectation is no longer 
valid. 



A process or rule which no one uses or enforces is just noise and distraction. 



It's a burden, both mentally and organizationally. 



No one will take you seriously if you dictate superfluous expectations and processes. Just don't do it. 



There's another set of expectations that are always required: CONSEQUENCES. We all think of these as negative, but they're not always. 




Once you've established the expectations you also have to establish what happens when those expectations are met or exceeded. 



Your team should never be in the position to ask "Or else what?" 
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https://www.openwest.org/code-of-conduct/ 


For example: the OpenWest code of conduct does a very good job of setting up both expectations and consequences 



Take care when establishing all of these processes and expectations. People, in general, are suspicious and somewhat resistant to change. 



Try not to add too many things at once or you'll overload people. Phase your changes in. 



It's like iterative development. 





Start small. Make a little change... 
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.run your tests to make sure you haven't changed expected functionality. 
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...make another small change... 



...test again and, uh, naturally fix anything that may be wrong. 
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By the end of the iterations you'll have a fully formed and functional process. 



If you make a lot of changes at once you'll break your relationship build and backing out the changes is nowhere near as simple as a "git revert". 




Subjecting people to a lot of changes at once makes them very uncomfortable and frustrated. It's really bad for team morale and productivity. 



There, are of course, many other things which can have a negative effect on morale and which you should try to avoid at all costs. 




Uncertainty... 



Gold-bricking team members... 
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Lack of managerial support... 


Version Not Supported 



Unappreciated 
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1 Thought his gossip exceedingly funny 

He told an odd story 
To sober John Dory \ \ 

With smiles that were cheerful and sunny 


I-. ■ ■ 
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See jokes even when they were clever \ 

The look of surprise vjKlK. 
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Will haunt, that poor Tunny forever • . 
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Unappreciated effort... 


Working on stuff that never gets used.. 




Boredom 



Bored people quit. 
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As a manager one of your most important tasks is to make sure that your team is challenged and that each of them grow professionally. 
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Professional development and training is important to a healthy relationship. 
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CONFERENCE 


Books, workshops, training sessions, conferences like this. These can all help prevent boredom and stagnation. 



I've actually fielded questions from new managers who are freaked out by the idea of helping their team learn. 



"But.. .they'll grow out of their current role and LEAVE!" 




Sure, they might. Or they'll grow out of their current role into a more senior role on your team. 



And I'll let you in on a little secret: It's all but inevitable that they're going to leave anyway. 


Let's have a show of hands. How many of you in this room have only had one job? OK, keep your hand up if you intend to keep that job for the rest of your professional life? Right. Point made. Hands down. 
People move on. It happens. Naturally you should try to minimize it. It's expensive--both in time and money--to hire and train new team members. But you need to be prepared for it and make departures 
friendly and productive. 


AND IT’S BYE -&Y£ > COOP 6V£» I TRIED... 



Do your best to keep team happy and productive and learning, but recognize that sometimes people just need to move on from a relationship. 



While, yes, fostering professional development has the potential to lead some people to evolve off your team its benefits far outweigh the risks. 
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You'll get increased productivity... 




...improved product quality... 
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BE A HAPPY WORKER! 


Iniage courtesy of Flickr User Personeelsnet; CC BY-SA 


...team members who are challenged and pleased to be at the office. 



Another good way to keep morale up is to dictate as little as possible. You'll need to assign tasks of course, but other than that I've found things go better 
if I tell people to do things as little as possible. 
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Stay 

in control 


at all 


times 


"Because I said so" is never a good reason for any of your team to do anything. Lead. Don't control. Just because you have authority it does not mean you 
have license to use it at every juncture. 



This isn't going to work unless you hire people you TRUST. Hire them, provide them the training they need, point them in the right direction, get all 
obstacles the hell out of their way and watch the magic happen. 



Trust is KEY. If you don't trust your team then you need to replace them because they were bad hires. If they're not bad hires then you just have trust 
issues which is WAY out of scope of this talk. 



Respect is the currency of the realm in tech management. Respect is impossible without trust 


Hire people you trust, 

Provide them the training they need, 
Point them in the right direction, 

Get all obstacles the hell out of their way 
And watch the magic happen. 


So let's go back to something I said a moment ago. 



Hire people you trust, 

Provide them the training they need, 
Point them in the right direction, 

Get all obstacles the hell out of their way 
And watch the magic happen. 


You cannot get things done through people if your people cannot get things done. This not only means getting your team the resources and training that 
they need to do their jobs, but it also means running interference for them. 



You are a human shield, protecting their time like the priceless treasure that it is. 
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You need to defend your team. Have their back. When Sales knocks on your door asking for a flying unicorn you need to be able to (politely) say "No, 
that's not possible right now and this is why," rather than taking on an unreasonable burden for your team. 



Are you lonely? 


Tired of working on your own? 
Do you hate making decisions? 


HOLD A MEETING! 


You can — 

• See people 

• Show charts 

• Feel important 

• Point with a stick 

• Eat donuts 

• Impress your colleagues 
All on company time! 



MEETINGS 
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THE PRACTICAL ALTERNATIVE TO WORK 


Also, you have to keep the meetings to a minimum. Don't have a meeting if an email will do. Don't invite more people than necessary just because you 
don't want someone to feel left out. Don't hold meetings w/o an agenda. Always start on time. Never run late. 




Your job is to attend meetings. Your team members are paid to code, to test, to document, to design. They are not paid to deal with administrative and 
political bullshit. You are. This is your responsibility. 
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When the shit hits the fan, the role of "The Fan" is played by you, not by your team. If you're not OK with that then please reconsider tech management 
as a career choice. 



Image courtesy of Flickr User Zhao !; CC BY 


Since we're on the topic of the less appealing aspects of tech management, you should know that it can be a fairly lonely job. 


Ml Reason for Chaf*9# 

Promotion 
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If you're moving into a management role within your organization you're suddenly likely to find that you can no longer talk to your work friends anymore. 




You're going to be dealing with a lot of things which are personnel related in one way or another. As I mentioned earlier, while in general 'open' is good, 
these things can't be shared with anyone. 



You can't really commiserate with your team. When Sales DOES show up asking for a flying unicorn you can't blow off steam by complaining about it in a 
team meeting. 



You cannot publicly throw other departments under the bus like that. It's patently uncool. Even if another team or department is populated entirely by 
asshats and chowderheads you do NOT vent to the team. Don't talk out of school. Don't be a jerk. Don't be That Person. 
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So while the other department is filled with asshats and chowderheads, your own is undoubtedly brimming over with brilliant, clever and interesting 
people.... 


People with whom you'd love to sit down and chat at the pub. 
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YOU. 


Performance reviews in Hell. 


People whose performance reviews you'll be writing. 


www. clos&ohome . com 




People you may one day need to lay off or fire. 



No matter what, be cautious when becoming friends with your team members. BY ALL MEANS be friendly and personable and get to know them as the 
spectacular humans that they are, but be careful if you become friends with any of them because you may need to hurt them some day. 



If you do a good job of relationship building then there'll be plenty of time to be friends with them after they (or you) inevitably move on. 


The big question... 



Now on to the big elephant in the room. 


“Will I still be able 
to code?!” 
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"Will I still be able to code?!" 




NO 



Image courtesy of Flic kr User Visionello; CC BY-NC 


Well. ..OK, maybe. A bit. Kinda. 
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When I'm not freelancing, this my work week. Granted, this example is a little severe but it's not too atypical. It also doesn't include time producing deliverables from all those meetings. If you were a 
manager or project manager, would you entrust features or bug fixes to someone with a schedule thus encumbered? You'd be a fool to put your product at risk that way. 



If you are hired as a tech manager then your primary responsibility is to manage. You are no longer paid to write code. 



That said, you still need to stay in the loop, technically speaking. If you don't you'll be incapable of making those informed decisions that I mentioned 
earlier if you don't understand the product, the code and the technology. So how do you do this? 



You can attend and run code reviews... 



You can run technical design meetings. 




You can (and should) read commit notes/diffs 


o 


L vmb'asseur / laupioad 

<>Cod» Iuum «S ' f\J nqmdi t WK ^ hi 

Oops. Lift iom« dtbug Wom In thsn. Rtmovsd now. 

Q[ vnWrmdur c om m m t cr* 1 % 15. 2014 
O ho mp i t**sng»d I— wW p tdd m o^i d*d 4 dssnis 

4 MM 

S 4 adfilt • if|i.MU«)U 
IS ft In • trpft.fll* 

41 S? ms 

SI I till tts SitiifliitlSA kiyt 

|| Mf 

♦ 

0 eomnurti on commit 


You can (and should) fix small bugs 
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Internet Archive S3 API: Documentation 


This document covers the technical details of usrig Internet Archive's S3~ike server API. aka "IAS3 " The 
intended audience is a technical user, deaJty one who is comfortable in the L/kixAJNlX command kne 
environment 

This document is an ^dependent work and a not written or supported by Internet Archve. Please use It in 
conjunction with the official IAS3 documentatoa See the support page lor more information about receiving 
support lor this document and IASS 

Contents 

• Introduction 

• • - ! : l! ?y FA:” 

• Getting Support lor This Documentation 

• Quck Start pending 

• System Requirements 

• Compatibility wth Amazon S3 

• Pas&ng Authorization Credentials to IAS3 

• Identfers 

• L" at • t~ rJ l*M 


You can write the documentation. 


PROTOTYPES 



Image courtesy of Flickr User 
noodlepie; CC BY-NC-SA 


You can assign yourself something larger to work on but only if it has a flexible or non-existent delivery date. 


Outrcachy 


Outreachy helps people from groups underrepresented in free and open source software get involved. We 
provide a supportive community for beginning to contribute any time throughout the year and offer focused 
internship opportunities twice a year with a number of free software organizations. 

Currently, internships are open internationally to women (cis and trans), trans men, and genderqueer 
people. Additionally, they are open to residents and nationals of the United States of any gender who are 
Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific 
Islander. We are planning to expand the program to more participants from underrepresented backgrounds 
in the future. 

Free and open source software organizations and supporting companies are invited to express interest in 
offering internships or sponsoring the program in the next round by August 22, 2016. Applications for the 
program will open on September 5 and the deadline for applying will be October 17. 

Participants 

Congratulations to 41 Interna accepted for May August 2016 round of Outreachyl Congratulations to * Interns, *ho applied for both Outreachy and Google 
Summer of Code, and after coordination between admirutfrator? 0 f both programs, were accepted for Google Summer of Code! 

https://www.gnome.org/outreachy/ 


You can mentor junior coders. 
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OpenHatch is a non-profit dedicated to matching prospective free 
software contributors with communities, tools, and education. 


We provide online tools for new contributors 


Build skills 


Find a project 


Get help 


Add your project 


practice with common 
FOSS technologes with 

our training missions - 


Drowse tasks across open 
source by skill, difficulty, 
or project ** 


ask us questions about 

finding projects and 
contributing • 


use this site to make your 
favorite project more 
welcoming • 


We organize and support outreach events 


Open Source Comes to Campus 

Through workshops at colegts. we teach the ncit generation ol students how to perhcpete n open source communities 

In-Person Event Handbook 

We share advice on rummo successful saints, hackathcns. and workshoos with new contributors to ooen source oroiects. 



And of course you always have open source. 




Just please don't make the mistake of thinking you'll still be able to contribute code at anything like the productive level you used to. 



If you try to balance both coding and managing you'll very quickly find that you're not doing either very well 



Goal 


So what's the end goal of all of this tech management claptrap? Not the business goals, but your personal goals for the management role? That's up to 
you, really. 




BEING 

DISPENSABLE 


As for myself, my goal is to make myself dispensable. No, really! If I can leave for a week and nothing goes off the rails then I know I've done my job well. It proves that I've hired the 
right people, trained them well, and set up and documented the procedures and expectations which meet their needs and the needs of my product and my company. 


Learn more 


Each one of these slides could probably become an essay. There's so much to say on this subject. So here are some ways you can learn more. 
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I lie Practice 
of 

Management 



Peter Drucker, "The Practice of Management," is a good place to start. It gives you a decent (if dated) foundation on management and business. 




"Managing Humans" by Michael Lopp, aka Rands of 'Rands in Repose' is a fun read that'll further introduce you to some of the challenges you'll face as 
you move from managing bits to managing people. 



Every single book by Bob Sutton should be required reading for most managers. His book titled "The No Asshole Rule" is one of my all-time favorites. 




Harvard 

Business 

Review 


THE MAGAZINE BLOGS VIDEO BOOKS CASES 


Registered | limited access 


HBR Blog Network Get daily posts in your inbox I 0 


http://blogs.hbr.org/ 


The Harvard Business Review blogs are a great place to learn new things. And, unlike the HBR itself (which is also a great resource, BTW), the blogs are 
free. 



The USA 



Become a Better Manager 
and Have a More Successful 


MANAGER fO&tS IS THE WORLD'S MOST AWAROCD BUSINESS POOCAST 


The World’* Bctt Bu*inc** Podcait 


https://www.manager-tools.com/ 




CTRBLLY 


Making 

Users 

Awesome 


No, it's not considered a management book. But it really, really should be. The mindset which goes to making your product's users awesome is very similar 
to the one which is needed to make your team awesome. Either way, you should read this book. 



zotero 
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Crash_Course_in_Tech_Management 


Recently Added Items 

nut 
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https://www.zotero.org/groups/ 

crash_course_in_tech_management/items 




VM (Vicky) Brasseur 


& @vmbrasseur 
^ vmbrasseur 

openwest@vmbrasseur.com 

http://anonymoushash.vmbrasseur.com 


And, of course, there's my own professional blog. There's also my Twitter stream if you don't mind sifting through me randomly talking about coffee & 
cats. If you have additional questions, you can also reach me via email @vmbrasseur.com. 


eval(empire) 


https://joind.in/event/openwest- 2016 / 

a-crash-course-in-tech-management 


http://archive.org/details/openwest 2016 -management 
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Q&A 


@vmbrasseur 

openwest@vmbrasseur.com 


http://archive.org/details/openwest 2016 -management 


Thanks for listening. Now, are there any questions? 


